Add CI workflow to build/package the VS extension - #30

Summary

Closes #29 — adds .github/workflows/build-vs-extension.yml, a CI workflow that builds, tests, and packages the Visual Studio extension (src/VisualStudio/Reqnroll.IdeSupport.VisualStudio.Extension).

Conventions followed from reqnroll/Reqnroll.VisualStudio's ci.yml

That repo's CI is the closest real-world analog for this task, since it's the legacy VS extension this project is meant to replace. It was fetched and read directly (gh api repos/reqnroll/Reqnroll.VisualStudio/contents/.github/workflows/ci.yml). Key conventions carried over:

• windows-latest runner — VSIX packaging needs Windows, not the ubuntu-latest used by reqnroll/Reqnroll's core CI or this repo's own build-vscode-extension.yml.
• microsoft/setup-msbuild to put msbuild.exe on PATH, since VSSDK packaging targets shell out to it even during a dotnet build/dotnet test invocation.
• dotnet restore before build, matching the explicit restore-then-build split in their build job.
• actions/upload-artifact@v4 with if-no-files-found: error for the VSIX and test results, and separating build vs. test into distinct jobs (mirroring their build / connector-tests / specs-tests split).

One deliberate divergence: Reqnroll.VisualStudio's legacy project is a classic net481 VSSDK package and needs an explicit msbuild -property:DeployExtension=false ... invocation to build. This repo's extension is an SDK-style csproj on the modern Microsoft.VisualStudio.Extensibility SDK (with VssdkCompatibleExtension/GeneratePkgDefFile for VSIX packaging). I verified locally that plain dotnet build/dotnet test already produce a working .vsix and pass all tests, so the workflow uses dotnet directly rather than blindly copying the msbuild.exe invocation — setup-msbuild is kept only so the VSSDK build targets can find msbuild.exe on PATH.

Also skimmed reqnroll/Reqnroll's own ci.yml for org-wide conventions (env block for shared vars, path-filtered/branch-filtered triggers, workflow_dispatch) — those already match this repo's build-vscode-extension.yml style, so no changes needed there.

Scope

No signing or Visual Studio Marketplace publish step is included — this repo has no marketplace credentials/secrets configured yet, and that's a decision for the maintainer. This matches build-vscode-extension.yml, which also stops at packaging the .vsix without publishing. reqnroll/Reqnroll.VisualStudio's release job (using CodingWithCalvin/GHA-VSMarketplacePublisher) is the reference to adopt later if/when publishing is desired.

Test plan

Locally validated (Windows, .NET SDK 10.0.301) by running the exact command sequence each job uses:

• dotnet restore src/VisualStudio/Reqnroll.IdeSupport.VisualStudio.Extension/Reqnroll.IdeSupport.VisualStudio.Extension.csproj — succeeds
• dotnet build ... --no-restore --configuration Release — succeeds, produces Reqnroll.IdeSupport.VisualStudio.Extension.vsix under bin/Release/net481/ (also verified Debug config separately)
• dotnet restore tests/VisualStudio/Reqnroll.VisualStudio.Tests/Reqnroll.VisualStudio.Tests.csproj — succeeds
• dotnet test ... --no-restore --configuration Release --logger trx — 74/74 tests pass

Not locally validated:

• microsoft/setup-msbuild itself (no MSBuild.exe present in this dev environment to compare against) — the build succeeded without it locally because dotnet build resolves the VSSDK targets/tools it needs from the restored NuGet packages, but I kept the action in the workflow per the reference repo's convention and because GitHub's windows-latest runner has a full VS Build Tools install where those targets may still shell out to msbuath.exe from PATH for manifest/pkgdef steps. This should be confirmed once the workflow runs on windows-latest in Actions.
• Actual GitHub Actions execution (runner-specific environment, caching, artifact upload) — should be verified on the first CI run against this PR.